【レポート】事業責任者も必見！AWS Well-Architected Frameworkのビジネスへの有効活用 #AWSSummit

AWS Summit Tokyo 2019

#AWS Well-Architected Framework

#イベントレポート

#AWS Well-Architected Tool

#AWS Well-Architected

#AWS

中川翔太

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、中川です。

2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。本記事は「事業責任者も必見！AWS Well-Architected Frameworkのビジネスへの有効活用」についてレポートします。

セッション概要

スピーカー（敬称略）：
・柘植翔太（株式会社サイバーエージェント技術本部・サービスリライアビリティグループ）
・岡田翔乃介（株式会社サイバーエージェント技術本部・サービスリライアビリティグループ）
セッション名：事業責任者も必見！AWS Well-Architected Framework のビジネスへの有効活用

本セッションでは、株式会社ASTROBOXが提供するサービスである「Ameba占い館SATORI」の事例を元に、プライベートクラウドで運用していたシステムを AWS へ移設する際、どのように AWS Well-Architected Framework を活用したのかについてお話しします。
また、私たちが独自に作っている CA Well-Architected Framework についてもお話しする予定です。

セッションレポート

以下、セッションレポートになります。
なお、Well-Architected Framework は、W-A の略称を使用させていただきます。

1. Introduction

所属する会社について
- 株式会社サーバーエージェント
所属する組織について
- 技術本部
  - 社内でメディア管轄と呼ばれているサイバーエージェントグループのメディアやグループを横断的にサポート
- サービスリライアビリティグループ
  - メディア管轄のサービスのインフラ領域を横断的にサポート
- メディア管轄と SRG の総管轄
  - ASTROBOX は Ameba 関連サービス
ASTROBOX について
- サイバーエージェント 100%出資子会社
- SATORI、SATORI 電話占い

2. Well-Architected Framework

システム移設にあたり抱えていた課題
- 移設の期限がすでに決まっている
- システム構成の悩み
- インフラチームへの依存
技術者への提案
- AWS についての学習
- 潜在的なリスクの可視化
- W-A を提案
AWS Well-Architected Framework とは
- システム設計・運用の大曲的な考え方とベストプラクティス集
- 最近では、AWS Well-Architected Framework Tool も発表され、セルフチェック可能に
ホワイトペーパーについて
- 5 つの柱によって構成
  - 運用上の優秀性
  - セキュリティ
  - 信頼性
  - パフォーマンス効率
  - コスト最適化
- 最近では、IoT やサーバーレス向けのホワイトペーパーも
よくある誤解
- AWS W-A を銀の弾丸だとおもっている
  - あくまで設計の原則
  - システムの健康診断として使える
- 監査的な使い方ができると思っている
  - 監査的な使い方は望ましくない
  - どう改善に取り組むかを一緒に考えることが重要
- 試しに 1 回実行してみたが良くならない
  - 定期的に実施し、チェックと改善のフローを継続的に回すことが重要
導入フロー
- 現状のシステム構成を整理
- 事前に確認質問集へ記入
  - 今は AWS W-A Tool を活用するといい
- AWS の SA 同席で、レビュー会を実施
  - 可能な限り技術責任者、決裁権をもつエンジニアが同席するといい
- 現状のシステム状態の分析
- Review Report を元に、システム改善（移設）計画を立てる
  - このステップが W-A で一番重要
    - 何が問題なのか
    - 問題に対して利害関係者は誰何か
    - 問題箇所の技術領域に詳しいのは誰か
    - 問題箇所を解決する上で誰が責任者か
- システム改善（移設）を元に実施
継続的なシステム改善について
- Enginieering Budget という考え方
  - サービスの売上変動に応じてエンジニアリング予算を確保
    - 新しいツールを導入しやすくする
    - エンジニアのコストも可視化して、事業成長できるように
導入サービスの技術責任者からの声
- ポジティブな意見
  - 運用周りのヒントを貰えたので、それをもとに改善していこうと思った
  - どういったセキュリティリスクがあるのかを認識することができて
  - 運用中のサービスをはじめて AWS に移設したが、安心して取り組めた
- その他の意見
  - 項目によっては回答が難しい
  - 課題はわかったが、事業レベルでどう取り組むべきか
  - 定期的にセルフチェックしたい

3. CA Well-Architected Framework

CA Well-Architected Framework とは
- AWS W-A を元に作成した、プラットフォームに依存しない汎用的なフレームワーク
- Yes/No だけで判別できるように
- 質問数を可能な限り少なく
- 内製だからできるカスタマイズ
  - Google Apps Script でレビュー結果の自動集計・解析や Slack 通知を実施する Bot
サービスを見つめ直すためのライフサイクル
- 学習
- 測定
- コミュニケーション
- 改善/事業貢献
開発者視点のメリット
- より迅速にかつ低リスク
- 体系的に
- 導入コストが低い
事業者視点のメリット
- どの事業でも提供することができる
- サービスの信頼性も向上する
- リスクを可視化することができる
CA W-A の実施フロー
- CONDITION REVIEW
  - 事前にサービスのコンディションチェック
- REVIEW REPORT
  - ORE とサービスのジグつ責任者でレビュー
- DISCUSSION & PLANNING
  - 技術責任者と事業責任者
- IMPROVEMENT
CONDITION REVIEW
- Google スプレッドシートでコンディションの質問集を管理
- カスタマイズした Slack ボタンから Slack にレビュー結果を連携
REVIEW REPORT
- Google ドキュメントを利用
- すべての項目に関して Suggetion を用意
- 詳細結果、改善案や事例 etc
DISCUSSION & PLANNING
- 2 回にわけて実施
- 事業と技術から優先度を話す
IMPROVEMENT
- 改善フロー
  - 合意が取れた解決すべき課題を改善
  - 改善事例として、社内外へ公開
  - 半期後に改善率チェック
- CA W-A はチェックシートではない
  - チェックした後のコミュニケーションに価値がある
SATORI の進捗
- 今は IMPROVEMENT
- レビュー結果
  - 優先して改善していく項目（CriticalIssue）に焦点を当てることに
- 以下のように分類
  - 6 月中に完了予定
  - 今期中に実施
  - 前 2 つが完了したら実施
- 技術責任者からの FB
  - どういうことに影響がでそうかまでまとめてきてくれたのでわかりやすかった
- 事業責任者からの FB
  - エンジニア以外も理解をしやすい内容であった
CA W-A の今後について
- 4 つに導入
- さらに 2 つに導入予定
- 2019 年下半期にやるべきこと
  - 自動で前回と光っく
  - 情報の最大化
  - AWS W-A Tool と統合
  - 母国語の形成
  - On-boarding の整備と公開

4. Summary

AWS W-A の可能性
- 体系的に AWS について学べる
- AWS を活用しているサービスであれば AWS W-A を試さない理由はない
プロダクトの成長をお手伝いするために CA W-A を作りました
- 事業視点と技術視点の双方から自サービスを見つめ直し、根本的な課題をクリアにするための道具
- チェックシートではないし、監査として使用するものではない

さいごに

AWS Well-Architected Frameworkとサイバーエージェント社で使用しているCA Well-Architected Frameworkの活用事例について、話していただきました。
W-A をチェックシートとして終わりにするのではなく、定期的に W-A を回すことが重要であり、そのために組織として改善できる環境作りも大事だと思いました。